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    BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional
                      Forwarding Detection (S-BFD)

Abstract

   Seamless Bidirectional Forwarding Detection (S-BFD) defines a
   simplified mechanism to use Bidirectional Forwarding Detection (BFD)
   with large portions of negotiation aspects eliminated, thus providing
   benefits such as quick provisioning as well as improved control and
   flexibility to network nodes initiating the path monitoring.  The
   link-state routing protocols (IS-IS and OSPF) have been extended to
   advertise the S-BFD Discriminators.

   This document defines extensions to the BGP - Link State (BGP-LS)
   address family to carry the S-BFD Discriminators' information via
   BGP.
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1.  Introduction

   Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] defines
   a simplified mechanism to use Bidirectional Forwarding Detection
   (BFD) [RFC5880] with large portions of negotiation aspects
   eliminated, thus providing benefits such as quick provisioning as
   well as improved control and flexibility to network nodes initiating
   the path monitoring.

   For the monitoring of a service path end to end via S-BFD, the
   headend node (i.e., Initiator) needs to know the S-BFD Discriminator
   of the destination/tail-end node (i.e., Responder) of that service.
   The link-state routing protocols (IS-IS [RFC7883] and OSPF [RFC7884])
   have been extended to advertise the S-BFD Discriminators.  With this,
   an Initiator can learn the S-BFD Discriminator for all Responders
   within its IGP area/level or optionally within the domain.  With
   networks being divided into multiple IGP domains for scaling and
   operational considerations, the service endpoints that require end-
   to-end S-BFD monitoring often span across IGP domains.

   BGP - Link State (BGP-LS) [RFC7752] enables the collection and
   distribution of IGP link-state topology information via BGP sessions
   across IGP areas/levels and domains.  The S-BFD Discriminator(s) of a
   node can thus be distributed along with the topology information via
   BGP-LS across IGP domains and even across multiple Autonomous Systems
   (ASes) within an administrative domain.

   This document defines extensions to BGP-LS for carrying the S-BFD
   Discriminators' information.

2.  Terminology

   This memo makes use of the terms defined in [RFC7880].

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  BGP-LS Extensions for S-BFD Discriminators

   BGP-LS [RFC7752] specifies the Node Network Layer Reachability
   Information (NLRI) for the advertisement of nodes and their
   attributes using the BGP-LS Attribute.  The S-BFD Discriminators of a
   node are considered a node-level attribute and are advertised as
   such.

   This document defines a new BGP-LS Attribute TLV called "S-BFD
   Discriminators TLV", and its format is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Discriminator 1                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Discriminator 2 (Optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               ...                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Discriminator n (Optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: S-BFD Discriminators TLV

   where:

   Type:  1032

   Length:  variable.  It MUST be a minimum of 4 octets, and it
      increments by 4 octets for each additional discriminator.

   Discriminator n:  4 octets each, carrying an S-BFD local
      discriminator value of the node.  At least one discriminator MUST
      be included in the TLV.

   The S-BFD Discriminators TLV can be added to the BGP-LS Attribute
   associated with the Node NLRI that originates the corresponding
   underlying IGP TLV/sub-TLV as described below.  This information is
   derived from the protocol-specific advertisements as follows:

   *  IS-IS, as defined by the S-BFD Discriminators sub-TLV in
      [RFC7883].

   *  OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in
      [RFC7884].

4.  IANA Considerations

   IANA has permanently allocated the following code point in the "BGP-
   LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
   TLVs" registry.  The column "IS-IS TLV/Sub-TLV" defined in the
   registry does not require any value and should be left empty.

         +================+======================+===============+
         | TLV Code Point | Description          | Reference     |
         +================+======================+===============+
         | 1032           | S-BFD Discriminators | This document |
         +----------------+----------------------+---------------+

          Table 1: S-BFD Discriminators TLV Code Point Allocation

5.  Manageability Considerations

   The new protocol extensions introduced in this document augment the
   existing IGP topology information that was distributed via BGP-LS
   [RFC7752].  Procedures and protocol extensions defined in this
   document do not affect BGP protocol operations and management other
   than as discussed in "Manageability Considerations" (Section 6) of
   [RFC7752].  Specifically, the malformed NLRIs attribute tests in
   "Fault Management" (Section 6.2.2) of [RFC7752] now encompass the new
   TLV for the BGP-LS NLRI in this document.

6.  Security Considerations

   The new protocol extensions introduced in this document augment the
   existing IGP topology information that can be distributed via BGP-LS
   [RFC7752].  Procedures and protocol extensions defined in this
   document do not affect the BGP security model other than as discussed
   in "Security Considerations" (Section 8) of [RFC7752], i.e., the
   aspects related to limiting the nodes and consumers with which the
   topology information is shared via BGP-LS to trusted entities within
   an administrative domain.

   The TLV introduced in this document is used to propagate IGP-defined
   information (see [RFC7883] and [RFC7884]).  The TLV represents
   information used to set up S-BFD sessions.  The IGP instances
   originating this information are assumed to support any required
   security and authentication mechanisms (as described in [RFC7883] and
   [RFC7884]).

   Advertising the S-BFD Discriminators via BGP-LS makes it possible for
   attackers to initiate S-BFD sessions using the advertised
   information.  The vulnerabilities this poses and how to mitigate them
   are discussed in [RFC7880].
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